Initially, we discussed the idea of using the protocol defined by last year’s team for this particular project, aiming to give us compatibility with their existing client and server. However, we decided against this in favour of creating our own protocol, mainly as it would give us more flexibility when it came to designing and implementing the client and server later on in the project. 

The first draft of the protocol specification defined the syntax along with some basic actions such as those required for logging in and sending messages. Additional actions and requests were added to the protocol as the server was designed and implemented, at which point it became obvious that splitting the messages into two different types --- actions and requests --- would make the protocol more clearly defined. Beyond this, the protocol has essentially remained the same as it was defined in the first draft, as problems only became apparent towards the end of the evaluation phase.

\section{Known Issues}

There are a number of small issues with the protocol design due to oversights and time constraints in testing. While these issues are not critical, they prevent the protocol from being as robust and flexible as originally intended.

There is no method for explaining why a particular sent message failed - only that it did in fact fail. For example, if a client send a message to a user and a failure occurs, they will be unable to determine if it is because that user is offline or if it is because that user does not exist.

There are also some security issues with the way in which channels work. The protocol defines no administrative features for channels, preventing an administrator – which also is not defined by the protocol - from removing malicious users from the channel. As anyone that is in that channel may also lock or invite users to that channel, there is the potential for abuse of this by malicious users. A user could, for example, potentially lock a channel repeatedly even if other users are trying to unlock it. Once those other users have left, the malicious user could then keep the channel locked indefinitely, essentially claiming that channel name until the server shuts down.